IBIS Macromodel Task Group Meeting date: 06 February 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai * Chi-te Chen Liwei Zhao Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): * Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi Randy Wolff Teraspeed Labs: Bob Ross Zuken USA: Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: Michael reported that a third-party open-source tool developer had approach him at DesignCon. The developer noted that our parser source code (tschk in this case) is not open source. The developer would be interested in utilizing the freely distributed parser executables if they provided access to data structures containing the parsed data. They asked for an API or some other way to get access to the data structures, as opposed to the executable's current operation as a syntax checker. The group decided this topic could best be handled in the Quality task group. ------------- Review of ARs: Michael: Develop a new clarification BIRD to more clearly define relationships between concepts, terms, and parameters such as block, block size, wave_size, etc. - In progress. Michael said we might have further discussion during this meeting about what needs to be clarified. Michael: Send draft2 of BIRD229.1 to the ATM list. - Done. Michael sent draft2 to the ATM list on January 23, 2024. Michael: Develop a full syntactically complete example demonstrating BIRD229.1. - Done. Michael said that unless there are any functional changes to the BIRD, version 2 of the example, which he had posted to GitHub, is complete. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the January 23rd meeting. Ambrish moved to approve the minutes. Walter seconded the motion. There were no objections. -------------- New Discussion: BIRD229.1 draft3: Michael shared BIRD229.1 draft3. He noted that draft3 was a work in progress and contained several editorial corrections he had received after sending out draft2. Michael reviewed the changes in draft2, including: - Replacing the phrase "size of each block of data" with "number of samples in the data passed to and received from" when describing what is specified by wave_size. This is to avoid potential confusion related to assumed units for the undefined term "block size". - The "time duration" of a block of data was replaced with "number of samples" for additional clarity. - The phrase "number of UI" was replaced with "number of symbol times". Arpad asked for confirmation that a UI (unit interval) corresponds to a symbol time for any PAMn. Walter confirmed, and the group agreed that UI is symbol time. Michael introduced a new change he wanted to make in draft3. He said that he had originally made AMI_output_parameters_file optional in an attempt to make things as convenient as possible for model makers. However, given that we are relying on this BIRD to provide the information necessary to address parser BUG227 (AMI root name checking), he wanted AMI_output_parameters file to be required instead of optional. He said that even if a model has no parameters to return, it should return the root name in AMI_parameters_out. By making AMI_output_parameters_file required, we can ensure that [AMI Test Configuration] allows the parser to check the returned root name. This would resolve BUG227. No one objected to making AMI_output_parameters_file a required subparameter. Walter offered comments on the proposal. He said his organization creates AMI models, and they already develop tests as part of that process. They would plan to give their designers the ability to take the tests they already have and convert them into the format of BIRD229.1. However, he said they typically only use the .ibs file as a minimal required wrapper. He asked why we would want to put all of this new test information in the .ibs file at all. He suggested that it would be better to add it to the .ami file. We could simply add an AMI Reserved parameter to point to a new file containing the test configuration information. He said that the existing proposal might force the model maker to add this test information to many different .ibs files that utilize the same underlying .dll/.so. Arpad agreed that Walter's proposal might be more efficient, because it would avoid repeating the same information in multiple [Model]s that contained [Algorithmic Model]s that relied on a common .dll/.so. Michael asked how Walter's proposal would replace the functionality provided by the Executable_index and Direction subparameters. He said Executable_index was there to provide multiple sets of golden result test data for various operating systems, 32 or 64 bit architectures, etc. This was anticipating that different versions of the same .dll (same underlying code) might use the same .ami file but return slightly different results. Walter said a comparison looking for strict equality was often going to fail, no matter how many different sets of results we provided. The exact same .so can return slightly different results on different machines. He said a real- world comparison would have to be toleranced, and this could involve concepts like relative tolerance and absolute tolerance. Michael said the precision of the data provided in the [AMI Test Configuration] results files might differ from what is being generated on a given test machine, and he agreed that a naive comparison looking for strict equality would likely fail. He said something like FSV or a different type of comparison algorithm might be valuable, but he wasn't proposing any particular form of comparison. However, with Executable_index, he was addressing the concern that the golden data sets might be slightly different for various operating systems, architectures, etc. He said perhaps we need to introduce a precision specification requiring the model maker to provide a certain minimum precision in the golden results files. Michael said he could envision ways in which the information provided by Executable_index could be added to the .ami file, but we would have to provide more information in the .ami file and might need to have a different .ami file for each of the different builds of the same .dll/.so. Walter said the two different approaches could provide the same functionality, but he thought the simplicity of putting the information in the .ami file outweighed the extra flexibility of the current BIRD229.1 proposal. Arpad noted that the results files in BIRD229.1 are in ASCII format. He said the precision of the numbers provided in ASCII format files is typically much lower than that needed to detect the small OS to OS or machine to machine differences. Arpad asked whether we should consider providing the results data in binary format to facilitate higher precision comparisons. Jared asked whether the user or tool could infer the precision to be used for the comparison from the precision of the data provided in the ASCII file. Michael noted that someone at DesignCon had asked whether we should support binary format in order to minimize the size of the waveform files. Ambrish said he thought the approach in BIRD229.1 was an effective use of the existing .ibs wrapper around the .ami model. Walter said he would prefer not to put the information in the .ibs file itself, but his organization would follow BIRD229.1 if it is approved. Michael said he would introduce the change to make AMI_output_parameters_file a required subparameter and send out draft3. - Curtis: Motion to adjourn. - Jared: Second. - Arpad: Thank you all for joining. New ARs: Michael: Send draft3 of BIRD229.1 to the ATM list. ------------- Next meeting: 13 February 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives